Jun 87 Letters
Volume Number: 3
Issue Number: 6
Column Tag: Letters
Pagemaker 2.0 Incompatible with 1.2
David E. Smith
Aldus Corp. released version 2.0 of Pagemaker today and MacTutor has found that
version 2.0 is incompatible with version 1.2 for placing formatted MacWrite files.
Under version 1.2, the left margin setting of MacWrite has always been ignored unless
the command key is held down, when reflowing formatted MacWrite files into
Pagemaker columns. This has become a feature, since it is very difficult to work with a
MacWrite window with the left margin set at 0. Under version 2.0, this left margin
setting is now automatically picked up by Pagemaker and the entire column of text is
indented by this amount. Since there is no way to stop this indentation, in order to get
MacWrite documents to correctly reflow into Pagemaker columns, you must go back
and re-format all of your MacWrite ruler settings to a left margin of 0. Even for a
single large document, this can be a job! And for the thousands of documents formatted
over the last two years, impossible! Since Aldus has indicated they do not intend to
change this, unless forced by the marketplace, MacTutor is encouraging a letter
writing campaign to force the addition of a dialog option to turn off automatic
indentation of MacWrite formatted files in version 2.0. Please write to Paul Brainerd
at Aldus, 411 First Ave. South, Suite 200, Seattle, WA 98104. MacTutor will be very
grateful.
TML Pascal and SANE
Alan Engard
Costa Mesa, CA
I’m having a hair-pulling experience with TML Pascal (and/or SANE) and hope
someone out there can help. The “Tan” and “XpwrY” calls to SANE fail consistently. It
creates an Address Error or Illegal Instruction Error depending on the individual
program. The failure occurs regardless of whether the parameters are constants or
variables, and occur in both plain-vanilla Pascal and all-Mac Pascal code.
Following is an example:
program test (input,output);
uses macint f, sane int f;
var
result :real;
begin
writeln(‘Tangent:’);
result:=Tan(3.1415926536); {TML crashes}
writeln(result);
end.
And I do know that at least some calls to SANE do work (although they are all
non-calculation oriented): Num2Str and ClassExtended.
MacUser (as early as the February issue) listed the current version of TML
Pascal as 2.01, while I have 2.0--is this right? If so, does this bug(?) still exist and
what else has been fixed/added/changed? (On that note I would like to suggest that you
mention development tool updates and briefly list their changes.) Thanks for all of
your invaluable information--keep up the good work!
[We tried the example in Lightspeed Pascal and it ran a tangent function from
SANE with no problems. I suggest you contact TML about updating to version 2.01 and
ask them about this bug. The update problem requires a full time person to keep up
with it. We haven’t found the time or money to hire such a person yet, but I agree the
job is needed. -Ed]
uses sane;
PROCEDURE doUser; {LS Pascal example}
VAR
result : extended;
str1 : str255;
str2 : DecStr;
f : DecForm;
BEGIN
result := Tan(3.1415926536);
f.style := FixedDecimal;
f.digits := 12;
Num2Str(f, result, str2);
str1 := ‘Tangent of Pi = ‘;
doMessage(str1, str2, ‘’, ‘’);
END;
McFace News
Dan Kampeier
Urbana, IL
[Chuck Bouldin is preparing a Fortran article on McFace. Unfortunately the
article didn’t get to MacTutor before Chuck went on vacation, which leaves us in the
humorous position of publishing the rebuttal before the review! However, Mr.
Kampeier has some good points, and McFace is a solid product so here is the author’s
comments to a review no one has seen yet! -Ed]
First, I would like to thank Chuck Bouldin for taking the time to review McFace.
Chuck is an avid user of McFace, and has contributed to the enhancement of McFace via
his many comments and suggestions. I would also like, however, to provide a further
explanation or clarification of the two major criticisms which Chuck made of McFace:
(1) its relatively large size, and (2) its use of numbers as arguments in calls to
McFace.
(1) One problem with the Absoft (Microsoft) Fortran compiler for the Mac is
that the object code which it generates is at least twice as large as that generated by the
Pascal or C compilers for the equivalent source code. This may be a trade-off for the
execution speed, but I’ve also heard that the compiler is simply not very efficient with
respect to the object code it generates. Now if you are stuck using such a compiler, the
obvious thing to avoid is duplicating source code from program to program, and this is
exactly what McFace does for you: it provides a single subroutine which can be used by
many different Fortran programs on the same disk. The second reason why McFace is
so large is simply that it does so much for you.
It contains code for file handling, text editing, picture handling, etc., as well as
functions such as “Copy Table” (replace spaces with tab), search & replace,
auto-indent, etc. If you use Fortran to create a program with most of the functionality
of McFace, I guarantee that it will be at least as large as McFace. Finally, memory is
going to continue to get cheaper, the Mac toolbox is going to continue to get more
powerful, and McFace is going to inevitably get bigger as user expectations rise ever
higher. (Look what has happened to the size of MS Word!)
(2) I experimented with many different methods of passing information between
the calling program and McFace, and settled on a scheme with three levels: (a) direct
“macro” commands are passed as arguments in the subroutine call, (b) often used
variables are shared in a common block with the calling program, and (c) seldom used
variables are stored in an array which the programmer can access as needed. Passing
macro commands as numbers (versus integer variable names as recommended by
Chuck) is preferred by most of the active users of McFace to whom I have talked. The
source is cleaner, and their are simply not that many different macro commands to
remember. Moreover, nearly all of the commands simply correspond to a McFace
menu and item number, so that anyone familiar with the McFace Apple, File, Edit, and
Window menus will also automatically know many of the macro command combinations.
Furthermore, use of integer variable names for numbers is not as easy as it sounds
since many of the McFace menu items are context sensitive (depend on which window is
at front), and some menus are of variable length (depend on number of windows in
use). Finally, nothing pr events a McFace user from simply creating integer variable
names to use in place of numbers in calls to McFace.
McFace continues to evolve. Version 3.0 will ship sometime early this summer
and should be compatible with the Mac II (Absoft was having trouble with some toolbox
calls on the Mac II with its current release). My continuing goal is to put as much
generic stuff into McFace as possible to facilitate the rapid development of fully
Mac-like programs in a minimum amount of time using Fortran.
Reprint
W.J. Meyers
Newsletter Editor
Hughes Mac-HAC’ers
Thank you for allowing us to reprint Loy Spurlock’s comments on the Mac’s
power supply problems from a past issue of MacTutor. I was told by Loy that you have
given your approval to con currently publish his article providing we acknowledged
your permission to reprint at the beginning of the article. A copy of our newsletter is
enclosed to prove that we complied with your wishes.
By the way, if you are still keeping tabs on the problems user’s are having with
their SCSI drives, please put my name on the list. I am having one hell of a time with
my ProApp 20 drive(s), but let me follow through to a conclusion before I tell you the
whole story.
32k Segment Limit-Revisited
S.C. Kim Hunter
Mission Viejo, CA
In MacTutor, March 87, I made a comment regarding a “fundamental” limit of
the 32k that is imposed in many of the compilers for the Mac, mainly Pascal, and
pointed out that MacFortran doesn’t have any of these limits, simply because Absoft
chose to ignore the Mac ROM segment loader when they wrote their compiler (actually
just ported it from something else).
To confirm my suppositions, I ran a test program in both Lightspeed Pascal and
MacFortran. Listings are enclosed. In Lightspeed Pascal, one can define an array of
integers up to 1..15497 in the global variable part, and in a procedure, up to
1..16375. Integers in Lightspeed Pascal are each two bytes, so these limits are close
to 32k (which should be 32768 bytes, or 1..16384 integers). If the dimensions are
increased by 1 more than these limits, the compiler politely puts up an error message
advising one of three messages: 1) “Project has more than 32k of globals”, 2)
“Available memory for variables declared at this level has been exhausted”, or 3)
“Variables of this type would be too large”. At which point these messages appear is
shown in the Lightspeed Pascal listing.
The same program done in MacFortran, and constricting integers to 2 bytes
(integer*2-the default is 4 bytes), compiles and runs perfectly at the dimensions
well over those of Lightspeed Pascal version. I ran the integer array dimension up to
about 150,000 before running in to problems (on a 512k Mac XL). Unlike the polite
messages of Lightspeed Pascal, MacFortran just overwrites and bombs (freeze, crash
to Macsbug, the gamit, out of control). The compiler has no messages, friendly or
otherwise, compiling and dimension with no grips. Only when the program runs do you
know if you exceeded the memory limit. If you add more RAM, the problem goes away
till you pump up to the new limit.
Lightspeed Pascal does edit, compile, run cycle in about 21 sec, good or bomb
(politely). MacFortran, if you insert an “execute(‘QUED 1.5’)” to auto re-enter the
editor takes about 1:20 min:sec for a good cycle, 2:40 min:sec for a crash/reboot on a
Mac XL. So you take your choice: small, quick, polite bytes with Lightspeed Pascal, or
Russian Roulette chomps with MacFortran.
I have passed these questions to Apple Macintosh Technical Support. They are
beyond my limited scope as a “high level programmer”. Only someone who has
actually read and understood Inside Macintosh and actual been inside a Macintosh could
answer the questions. I am too big and fat to fit that spec. Andy Hertzfeld is small but
fat (and cute! but that doesn’t count except when his software crashes-then he’s not so
cute!).
We soon will have Macs with 4 megabytes (some have them now). Are we only
allowed to swallow them in 32k chunks? Lets see, 4,096,000 divided by 32,768 is...
How many chunks?
Don’t expect the answer to come from Think Technologies. At $89 per package,
they can hardly pay for Steve Stein to answer the phone (which he now doesn’t seem to